Boomi Process Route Step: The Complete Guide to Dynamic Process Routing

Leave a CommentBoomi Process Route Step: The Complete Guide to Dynamic Process RoutingBoomi Integration, Tools and Platforms

Ever found yourself creating dozens of nearly-identical processes just because you need slightly different logic for different customers, document types, or regions? Or maybe you’ve built a massive process with 50+ branches trying to handle every possible routing scenario in one place?

There’s a better way: the Process Route Step.

In this comprehensive guide, I’ll show you how to leverage Boomi’s Process Route Step to build flexible, scalable integrations that adapt at runtime without code changes or redeployments. You’ll learn when to use it, when not to, and see real-world examples that will transform how you architect your Boomi solutions.

Table of Contents

  1. What is the Process Route Step?
  2. Process Route vs Process Call vs Route Step
  3. How Process Route Works
  4. Setting Up Your First Process Route
  5. Real-World Use Cases
  6. Passthrough vs Non-Passthrough Subprocesses
  7. Deployment Strategies and Considerations
  8. Process Properties and Extensions with Process Route
  9. Best Practices and Design Patterns
  10. Common Pitfalls and How to Avoid Them
  11. When NOT to Use Process Route
  12. Advanced Patterns

What is the Process Route Step?

The Process Route Step is Boomi’s advanced workflow tool that allows you to dynamically select which subprocess to execute at runtime based on document properties, data values, or configuration settings.

Think of it as a smart dispatcher: it looks at incoming data, checks routing rules you’ve defined, and automatically sends documents to the appropriate processing pipeline—all without hardcoding the logic in your parent process.

Key Characteristics:

  • Dynamic resolution: Subprocess is determined at runtime, not build time
  • Independent deployment: Parent process, Process Route component, and subprocesses deploy separately
  • Centralized routing logic: All routing rules managed in one Process Route component
  • Scalable: Add new routing paths without changing parent process

Available In:

  • Professional and Enterprise editions only (Advanced Workflow feature)
  • Not available in Standard edition

Why It Matters:

Imagine you’re building an order processing integration that needs to handle:

  • 50 different customers, each with custom mapping requirements
  • 10 document types (orders, invoices, shipments, etc.)
  • Multiple target systems based on business rules

Without Process Route, you’d need:

  • 500 separate processes (50 customers × 10 document types), OR
  • One massive process with 500 branches, OR
  • Complex nested Route and Process Call steps

With Process Route:

  • 1 parent process
  • 1 Process Route component with routing rules
  • 50-100 focused subprocesses for actual processing
  • Easy to add new customers or document types

Process Route vs Process Call vs Route Step

Let’s clear up the confusion between these three related but different concepts.

FeatureRoute StepProcess Call StepProcess Route Step
What it doesRoutes documents down different paths in same processCalls another subprocessDynamically routes to different subprocesses
Routing decisionBuild time (fixed paths)Build time (fixed subprocess)Runtime (dynamic)
DeploymentPart of parent processDeployed with parentIndependent deployment
Subprocess selectionN/A (just routing)StaticDynamic based on data
Use caseSimple branching logicReusable common tasksMultiple customer/document-specific processing
ComplexityLowMediumHigh
ScalabilityPoor (adds branches)GoodExcellent
MaintenanceHigh (modify parent)MediumLow (modify component only)

Visual Comparison

Route Step:

Parent Process
├─ Route by customer
   ├─ Customer A → Map A → Write to System
   ├─ Customer B → Map B → Write to System
   └─ Default → Error handling

All logic in one process. Adding customers requires modifying and redeploying parent.

Process Call Step:

Parent Process
├─ Process Call: Validation_Subprocess (fixed)
└─ Process Call: Transform_Subprocess (fixed)

Always calls the same subprocesses. Good for standard workflows.

Process Route Step:

Parent Process
├─ Process Route: Route_By_Customer (dynamic!)
   └─ Checks document at runtime
      ├─ Routes to Customer_A_Process
      ├─ Routes to Customer_B_Process
      └─ Routes to Default_Process

Subprocess determined at runtime. Add customers by deploying only Process Route component.

When to Use Each

Use Route Step when:

  • Simple branching within same process
  • 2-5 routing paths
  • Logic is stable and won’t change often
  • All processing happens in parent process

Use Process Call Step when:

  • Calling specific, known subprocess
  • Reusing common logic (error handling, validation, audit)
  • Coordinating multiple processes in sequence
  • Subprocess doesn’t need to vary based on data

Use Process Route Step when:

  • Routing to different subprocesses based on data
  • Multiple customers/partners with custom logic
  • Frequently adding new routing paths
  • Need independent deployment of routing rules and subprocesses
  • Scaling to 10+ routing scenarios

How Process Route Works

Let’s break down the architecture and execution flow.

Components Involved

1. Parent Process

  • Contains the Process Route Step
  • Passes documents to subprocess
  • Continues after subprocess completes (if “Wait for process” is checked)

2. Process Route Component

  • Independent, reusable component
  • Defines routing rules and keys
  • Maps keys to specific subprocesses
  • Can have default route for unmatched keys

3. Subprocesses

  • Actual processing logic
  • Start with Data Passthrough enabled (usually)
  • Can return documents to parent via Return Documents step
  • Each deploys independently

Execution Flow

1. Documents reach Process Route Step in parent process
2. Process Route extracts "route key" from document
   - Key can be from document property, profile field, extension, etc.
3. Process Route Component looks up the key
   - Finds matching subprocess in routing rules
   - Or uses default subprocess if no match
4. Subprocess executes with the documents
5. If "Wait for process to complete" is checked:
   - Parent waits for subprocess to finish
   - Receives any returned documents
   - Continues execution
6. If not waiting:
   - Parent continues immediately
   - Subprocess runs asynchronously

Key Concepts

Route Key: The value used to determine which subprocess to call. Examples:

  • Document property: {1:customer_id}
  • Profile data: {1:OrderType}
  • Process property: {1:Config.region}
  • Trading partner ID (for EDI scenarios)

Passthrough Mode: When subprocess has “Data Passthrough” enabled:

  • Documents flow from parent → subprocess
  • Subprocess processes entire batch together
  • Can return results to parent

Non-Passthrough Mode: When “Data Passthrough” is NOT enabled:

  • Subprocess is called once per document
  • Each document triggers separate execution
  • No documents passed from parent

Setting Up Your First Process Route

Let’s walk through a complete example: routing customer orders to different mapping processes based on customer ID.

Scenario

You have 3 customers (A, B, C), each requiring different mappings to convert their order format to your standard format.

Step 1: Create Subprocesses

Subprocess: Customer_A_Order_Mapping

Start (Data Passthrough: ON)
└─ Map: Customer_A_to_Standard
   └─ Return Documents (label: "Mapped Orders")

Subprocess: Customer_B_Order_Mapping

Start (Data Passthrough: ON)
└─ Map: Customer_B_to_Standard
   └─ Return Documents (label: "Mapped Orders")

Subprocess: Customer_C_Order_Mapping

Start (Data Passthrough: ON)
└─ Map: Customer_C_to_Standard
   └─ Return Documents (label: "Mapped Orders")

Subprocess: Default_Order_Handler

Start (Data Passthrough: ON)
└─ Notify: Unknown customer error
   └─ Stop

Key Points:

  • All subprocesses have Data Passthrough enabled
  • All use Return Documents to send results back to parent
  • Default handler for unexpected customers

Step 2: Create Process Route Component

  1. Create Component:
    • Go to Build → Create New → Process Route
    • Name: Customer_Order_Router
  2. Configure Routing Keys:
   Key: CUSTOMER_A → Process: Customer_A_Order_Mapping
   Key: CUSTOMER_B → Process: Customer_B_Order_Mapping
   Key: CUSTOMER_C → Process: Customer_C_Order_Mapping
   Default → Process: Default_Order_Handler
  1. Enable Passthrough:
    • ☑ Passthrough (in Process Route component)
    • This groups documents by key and calls subprocess once per key

Step 3: Create Parent Process

Start
└─ Get Orders from SFTP
   └─ Parse XML
      └─ Set Properties (extract customer ID to document property)
         └─ Process Route: Customer_Order_Router
            ├─ Route By: {1:CUSTOMER_ID} (document property)
            └─ Wait for process to complete: ☑
               └─ "Mapped Orders" branch
                  └─ Write to Database
                     └─ Stop

Configuration:

Process Route Step Settings:
- Route By: Process Route
- Select Component: Customer_Order_Router
- Route Parameter: {1:CUSTOMER_ID}
  (document property set earlier)
- Wait for process to complete: Checked
- Abort if subprocess fails: Checked

Step 4: Deploy Components

Critical Order:

  1. Deploy all subprocesses first
  2. Deploy Process Route component
  3. Deploy parent process

Why? At deploy time, Boomi validates that:

  • Process Route component references valid processes
  • Those processes are already deployed

Step 5: Test the Flow

Test Document 1:

xml

<Order>
  <CustomerID>CUSTOMER_A</CustomerID>
  <Items>...</Items>
</Order>

Result: Routed to Customer_A_Order_Mapping

Test Document 2:

xml

<Order>
  <CustomerID>CUSTOMER_X</CustomerID>
  <Items>...</Items>
</Order>

Result: Routed to Default_Order_Handler (error notification sent)

Real-World Use Cases

Let’s explore practical scenarios where Process Route excels.

Use Case 1: Multi-Customer EDI Integration

Scenario: You’re an EDI provider processing orders from 100+ trading partners. Each partner has unique requirements:

  • Different mapping logic
  • Different validation rules
  • Some partners need additional enrichment
  • Various error notification preferences

Without Process Route:

  • 100+ separate processes, OR
  • One giant process with 100+ Route branches

With Process Route:

Parent Process:

Start (Trading Partner Listener)
└─ Process Route: Trading_Partner_Router
   ├─ Route By: {1:tp_id} (Trading Partner ID)
   └─ Wait for complete: ☑
      └─ Send to Target System

Process Route Component: Trading_Partner_Router

Route Keys:
- TP_WALMART → Process: Walmart_EDI_Handler
- TP_TARGET → Process: Target_EDI_Handler
- TP_AMAZON → Process: Amazon_EDI_Handler
- ... (100 more)
- Default → Process: Standard_EDI_Handler

Subprocesses (Example: Walmart_EDI_Handler):

Start (Data Passthrough: ON)
└─ Validate: Walmart-specific rules
   └─ Map: Walmart_850_to_Internal
      └─ Enrich: Add Walmart account data
         └─ Return Documents: "Processed Orders"

Benefits:

  • Add new trading partner: Just deploy new subprocess + update Process Route component
  • No changes to parent process
  • Each partner’s logic is isolated
  • Easy to troubleshoot per-partner issues

Adding a New Partner:

1. Create: NewPartner_EDI_Handler subprocess
2. Deploy subprocess
3. Edit Trading_Partner_Router component:
   - Add key: TP_NEWPARTNER → NewPartner_EDI_Handler
4. Deploy Trading_Partner_Router component
5. Done! (Parent process unchanged)

Use Case 2: Multi-Region Data Processing

Scenario: Your company operates in North America, Europe, and Asia. Each region has:

  • Different data privacy regulations (GDPR, etc.)
  • Different target systems
  • Different business hour processing windows
  • Region-specific data transformations

Solution: Region-Based Dynamic Routing

Parent Process:

Start (API Listener: Receive Customer Data)
└─ Set Properties: Extract region from data
   └─ Process Route: Region_Data_Router
      ├─ Route By: {1:REGION_CODE}
      └─ Wait: ☑
         └─ Return success/failure response

Process Route Component: Region_Data_Router

Keys:
- NA → Process: NorthAmerica_Data_Handler
- EU → Process: Europe_GDPR_Handler  
- APAC → Process: Asia_Data_Handler
- Default → Process: Invalid_Region_Handler

Europe Subprocess (GDPR-Compliant):

Start (Data Passthrough: ON)
└─ Validate: GDPR consent fields present
   └─ Map: Apply data minimization rules
      └─ Encrypt: PII fields
         └─ Decision: Business hours check
            ├─ Yes: Write to EU System immediately
            └─ No: Queue for next business window
               └─ Return Documents: "Processed"

North America Subprocess:

Start (Data Passthrough: ON)
└─ Validate: US data requirements
   └─ Map: Standard transformation
      └─ Write to NA System
         └─ Return Documents: "Processed"

Benefits:

  • Compliance: Region-specific rules enforced automatically
  • Flexibility: Change EU logic without affecting NA/APAC
  • Scalability: Add new regions easily
  • Maintainability: Regional teams can own their subprocesses

Use Case 3: Document Type-Based Processing

Scenario: You receive multiple document types in a single integration endpoint:

  • Invoices
  • Purchase Orders
  • Shipping Notices
  • Payment Confirmations

Each document type needs completely different processing.

Solution: Dynamic Document Type Routing

Parent Process:

Start (SFTP: Poll documents folder)
└─ Parse XML: Extract document type
   └─ Set Properties: DOCUMENT_TYPE from XML
      └─ Process Route: Document_Type_Router
         ├─ Route By: {1:DOCUMENT_TYPE}
         └─ Wait: ☑
            └─ Archive processed file

Process Route Component: Document_Type_Router

Keys:
- INVOICE → Process: Invoice_Processing
- PO → Process: PurchaseOrder_Processing
- SHIPNOTICE → Process: Shipping_Processing
- PAYMENT → Process: Payment_Processing
- Default → Process: Unknown_Document_Handler

Invoice Processing Subprocess:

Start (Data Passthrough: ON)
└─ Validate: Invoice schema
   └─ Map: Invoice to Accounting System format
      └─ Decision: Amount > $10,000?
         ├─ Yes: Route to Approval Workflow
         └─ No: Post directly to GL
            └─ Return Documents: "Processed Invoices"

Purchase Order Processing Subprocess:

Start (Data Passthrough: ON)
└─ Validate: PO schema
   └─ Check Inventory availability
      └─ Map: PO to ERP format
         └─ Create in ERP
            └─ Generate PO Acknowledgment
               └─ Return Documents: "Acknowledgments"

Use Case 4: Priority-Based Processing

Scenario: Orders need different processing speeds based on priority:

  • Priority 1: Real-time processing (urgent orders)
  • Priority 2: Fast batch (processed every 15 minutes)
  • Priority 3: Standard batch (processed hourly)

Solution: Priority-Based Subprocess Routing

Parent Process:

Start (API Listener or Scheduled)
└─ Get Orders from Queue
   └─ Set Properties: Calculate priority based on order value, customer, SLA
      └─ Process Route: Priority_Router
         ├─ Route By: {1:PRIORITY_LEVEL}
         └─ Wait: ☑ (for P1), ☐ (for P2/P3)

Process Route Component: Priority_Router

Keys:
- P1_URGENT → Process: Realtime_Order_Processor
- P2_FAST → Process: Fast_Batch_Processor
- P3_STANDARD → Process: Standard_Batch_Processor
- Default → Process: Standard_Batch_Processor

P1 Subprocess (Real-time):

Start (Data Passthrough: ON)
└─ Process Mode: Low Latency
   └─ Validate & Transform (minimal steps)
      └─ Post to ERP immediately
         └─ Send confirmation notification
            └─ Return Documents: "Confirmation"

P3 Subprocess (Standard Batch):

Start (Data Passthrough: ON)
└─ Aggregate orders into batch
   └─ Perform extensive validation
      └─ Enrich with additional data
         └─ Optimize posting order
            └─ Bulk post to ERP
               └─ Return Documents: "Batch Summary"

Benefits:

  • Resource optimization: P1 uses fast processing, P3 uses efficient batching
  • Different error handling per priority
  • SLA compliance: Critical orders always processed quickly
  • Easy to adjust priority logic without changing subprocesses

Use Case 5: A/B Testing and Feature Rollout

Scenario: You want to gradually roll out a new integration logic to a subset of customers before going live for everyone.

Solution: Feature Flag-Based Routing

Parent Process:

Start
└─ Get customer configuration
   └─ Set Properties: FEATURE_FLAG based on customer settings
      └─ Process Route: Feature_Router
         ├─ Route By: {1:FEATURE_FLAG}

Process Route Component: Feature_Router

Keys:
- NEW_LOGIC → Process: New_Integration_V2
- OLD_LOGIC → Process: Current_Integration_V1
- BETA → Process: Beta_Integration_With_Logging
- Default → Process: Current_Integration_V1

New Logic Subprocess:

Start (Data Passthrough: ON)
└─ Execute new transformation logic
   └─ Enhanced error handling
      └─ Return Documents

Rollout Strategy:

Phase 1: Set 5% of customers to BETA
  - Monitor logs and errors closely
  - Collect performance metrics
  
Phase 2: Set 20% to NEW_LOGIC
  - Compare against OLD_LOGIC performance
  
Phase 3: Set 50% to NEW_LOGIC
  - Validate at scale
  
Phase 4: Set 100% to NEW_LOGIC
  - Update default route

Phase 5: Remove OLD_LOGIC subprocess
  - Clean up unused processes

Benefits:

  • Risk mitigation: Limited blast radius if issues occur
  • Easy rollback: Change Process Route component only
  • Performance comparison: A/B test at scale
  • Gradual migration: Move customers in waves

Use Case 6: Tenant-Specific Multi-Tenant SaaS

Scenario: You’re providing integration-as-a-service to multiple SaaS tenants. Each tenant has:

  • Custom connection endpoints
  • Unique business rules
  • Different data mappings
  • Specific error notification preferences

Solution: Tenant-Isolated Processing

Parent Process:

Start (Shared API Endpoint)
└─ Authenticate & Extract Tenant ID
   └─ Set Properties: TENANT_ID from auth token
      └─ Process Route: Tenant_Router
         ├─ Route By: {1:TENANT_ID}
         └─ Wait: ☑
            └─ Return API response

Process Route Component: Tenant_Router

Keys:
- TENANT_001 → Process: Tenant_001_Integration
- TENANT_002 → Process: Tenant_002_Integration
- ... (hundreds of tenants)
- Default → Process: Invalid_Tenant_Handler

Per-Tenant Subprocess:

Start (Data Passthrough: ON)
└─ Load tenant-specific configurations
   └─ Apply tenant-specific transformations
      └─ Connect to tenant-specific endpoints
         └─ Apply tenant-specific validation
            └─ Return Documents: "Results"

Benefits:

  • Complete isolation: One tenant’s logic never affects another
  • Easy onboarding: Deploy new tenant subprocess
  • Per-tenant customization: Each can have completely different logic
  • Security: Tenant data never mixes in routing

Passthrough vs Non-Passthrough Subprocesses

Understanding this distinction is crucial for proper Process Route implementation.

Passthrough Mode (Data Passthrough = ON)

Configuration:

Subprocess Start Step:
☑ Data Passthrough

Behavior:

  • Documents flow from parent → subprocess
  • Subprocess processes entire batch as one execution
  • Can return documents to parent via Return Documents step
  • Parent waits (if configured) for subprocess to complete

When to Use: ✅ Processing multiple documents together ✅ Need to return results to parent ✅ Batch operations (aggregation, grouping) ✅ Most common pattern with Process Route

Example:

Parent sends 100 orders to subprocess
→ Subprocess receives all 100 orders
→ Processes them as a batch
→ Returns 100 transformed orders back to parent

Non-Passthrough Mode (Data Passthrough = OFF)

Configuration:

Subprocess Start Step:
☐ Data Passthrough (unchecked)

Behavior:

  • No documents passed from parent
  • Subprocess called once per document
  • 100 documents = 100 separate subprocess executions
  • Cannot return documents to parent

When to Use: ✅ Subprocess is self-contained (has own Start connector) ✅ Need to trigger independent workflow per document ✅ Fire-and-forget scenarios ✅ Rare with Process Route

Example:

Parent sends 100 orders to subprocess
→ 100 separate executions of subprocess
→ Each execution starts fresh (no documents from parent)
→ Each must have own Start connector to get data

Visual Comparison

Passthrough Enabled:

Parent Process (100 documents)
└─ Process Route Step
   └─ Subprocess Execution #1
      ├─ Receives: All 100 documents
      ├─ Processes: As a batch
      └─ Returns: 100 results

Passthrough Disabled:

Parent Process (100 documents)
├─ Process Route Step (Doc 1) → Subprocess Execution #1
├─ Process Route Step (Doc 2) → Subprocess Execution #2
├─ ... (98 more)
└─ Process Route Step (Doc 100) → Subprocess Execution #100

Best Practice

Default to Passthrough Mode (ON)

Unless you have a specific reason, always use passthrough:

  • More efficient (one execution vs many)
  • Can return results
  • Easier to debug (one execution log vs hundreds)
  • Better for batch processing

Exception: Use Non-Passthrough when:

  • Subprocess needs to start independently
  • Each document triggers completely separate workflow
  • You specifically want isolated executions

Deployment Strategies and Considerations

Process Route components require special deployment attention due to independent deployment.

Deployment Architecture

Three Independent Deployable Units:

  1. Parent process
  2. Process Route component
  3. Each subprocess

Unlike Process Call, where subprocess deploys with parent, Process Route components deploy separately.

Deployment Order

✅ Correct Order:

1. Deploy all subprocesses first
2. Deploy Process Route component
3. Deploy parent process

Why?

  • Process Route component references subprocesses (they must exist)
  • Parent process references Process Route component (it must exist)

❌ Wrong Order (will fail):

1. Deploy parent process
   ↓
   Error: Process Route component not found

2. Deploy Process Route component
   ↓
   Error: Referenced subprocesses not found

Update Scenarios

Scenario 1: Modify Subprocess Logic

Action: Change mapping in Customer_A_Order_Mapping
Deploy: Only Customer_A_Order_Mapping subprocess
Impact: Zero downtime for other customers

Scenario 2: Add New Routing Path

Action: Add new customer
Steps:
  1. Create and deploy Customer_D_Order_Mapping
  2. Edit Process Route component (add CUSTOMER_D key)
  3. Deploy Process Route component
Deploy: New subprocess + Process Route component
Impact: Parent process unchanged

Scenario 3: Change Routing Logic

Action: Route Customer A to different subprocess
Steps:
  1. Edit Process Route component
  2. Update CUSTOMER_A key → New subprocess
Deploy: Only Process Route component
Impact: No parent process deployment needed

Environment Promotion

Development → Test → Production

Traditional Approach (with dependencies):

Problem: Must deploy parent + all children together
Risk: All-or-nothing deployment

Process Route Approach:

Benefit: Deploy components independently
Strategy:
  1. Promote and deploy subprocesses first
  2. Promote and deploy Process Route component
  3. Promote and deploy parent process (if changed)

Rollback Strategy

If Subprocess Has Issues:

1. Fix subprocess
2. Redeploy only that subprocess
3. Other customers unaffected

If Process Route Logic Has Issues:

1. Redeploy previous version of Process Route component
2. All subprocesses remain unchanged
3. Parent process remains unchanged

Deployment Best Practices

1. Version Control Your Process Route Component

Component Names:
- Customer_Order_Router_v1
- Customer_Order_Router_v2

Strategy:
- Keep old version deployed during transition
- Test new version in parallel
- Switch parent process reference when ready

2. Use Deployment Packages

Package: Customer_Onboarding_Release_v2.3
Contains:
- New_Customer_Subprocess
- Updated_Process_Route_Component
- (Optional) Parent_Process_if_changed

Deploy entire package as unit

3. Deployment Checklist

☐ All subprocesses deployed in target environment
☐ Process Route component references correct subprocess names
☐ Subprocess names match between environments
☐ Test routing with sample data
☐ Verify default route handles unexpected keys
☐ Check logs for routing errors

4. Naming Conventions

✅ Good: Use consistent names across environments
  - Customer_A_Handler (same in Dev/Test/Prod)

❌ Bad: Different names per environment
  - DEV_Customer_A_Handler
  - PROD_Customer_A_Handler
  (Process Route component needs different configs per env)

Process Properties and Extensions with Process Route

Process Properties behave differently with Process Route compared to Process Call.

Key Difference

With Process Call:

  • Extensions defined in parent apply to parent AND children
  • Properties set in parent are visible in children
  • Single deployment unit

With Process Route:

  • Extensions defined in parent apply ONLY to parent
  • Extensions defined in subprocess apply ONLY to that subprocess
  • Must define extensions in each if using same component

Example Scenario

Parent Process uses Database Connection:

Parent Process:
  - Uses connector: Customer_DB
  - Extension defined: host, port, credentials

Subprocess ALSO uses same connector:

Subprocess: Customer_A_Handler
  - Uses connector: Customer_DB
  - ❗Must also define extension for host, port, credentials

Why? Parent and subprocess deploy independently, so each needs its own extensions.

Process Properties Behavior

Process Properties have execution scope, meaning once set, they persist through parent and children.

Example:

Parent Process:
1. Set Process Property: REGION = "NA"
2. Call Process Route Step

Subprocess:
3. Retrieve REGION property
   → Value is still "NA" from parent

4. Set Process Property: REGION = "EU"

5. Return to parent

Parent continues:
6. Retrieve REGION property
   → Value is now "EU" (changed by subprocess)

Implication: Process Properties are shared across parent and all subprocesses in the execution.

Best Practice:

✅ Use Process Properties for shared data across execution
  - Execution context (user ID, request ID)
  - Shared configuration needed by multiple processes

❌ Don't rely on default/extended values changing mid-execution
  - Once set, the property value persists

Extensions Management Strategy

Option 1: Duplicate Extensions (Most Common)

Parent Process Extensions:
  - Database_Host = prod-db.company.com
  - API_URL = https://api.company.com

Customer_A_Subprocess Extensions:
  - Database_Host = prod-db.company.com (same value)
  - API_URL = https://api.company.com (same value)

Pro: Clear, explicit
Con: Duplicate configuration

Option 2: Use Process Properties

Parent Process:
  - Set Process Properties from extensions
  - BEFORE calling Process Route

Subprocesses:
  - Read Process Properties (not extensions)
  - No need for duplicate extensions

Pro: No duplication
Con: Must remember to set properties before routing

Best Practices and Design Patterns

1. Always Provide a Default Route

❌ Bad: No Default

Process Route Keys:
- CUSTOMER_A → Subprocess_A
- CUSTOMER_B → Subprocess_B
(No default)

Problem: Unknown customers cause process failure

✅ Good: Default Route

Process Route Keys:
- CUSTOMER_A → Subprocess_A
- CUSTOMER_B → Subprocess_B
- Default → Unknown_Customer_Handler

Default Handler Subprocess:

Start (Data Passthrough: ON)
└─ Log error: Unknown customer
   └─ Send notification to operations team
      └─ Archive document for investigation
         └─ Return Documents: "Errors"

2. Use Descriptive Route Keys

❌ Bad Keys:

Keys: 1, 2, 3, 4, 5

Problem: What do these numbers mean?

✅ Good Keys:

Keys: 
- WALMART_PURCHASE_ORDER
- TARGET_INVOICE
- AMAZON_SHIP_NOTICE

Benefit: Self-documenting, easy to understand

3. Organize Subprocesses Logically

Folder Structure:

/Integrations
  /Customer_Order_Processing
    /Parent_Processes
      - Order_Intake_Main
    /Routing_Components
      - Customer_Order_Router
    /Customer_Subprocesses
      /Customer_A
        - Customer_A_Order_Handler
        - Customer_A_Validation
      /Customer_B
        - Customer_B_Order_Handler
        - Customer_B_Validation
    /Common_Subprocesses
      - Standard_Error_Handler
      - Default_Router_Handler

4. Implement Consistent Return Documents

All subprocesses should use consistent Return Documents labels:

Success path: Return Documents: "Success"
Error path: Return Documents: "Errors"

Benefits:

  • Parent process branches are predictable
  • Easy to find success/error paths in logs
  • Consistent across all routing scenarios

5. Add Monitoring and Alerting

Include monitoring in each subprocess:

Start (Data Passthrough: ON)
└─ Set Properties: START_TIME = current timestamp
   └─ Try-Catch
      ├─ Process customer-specific logic
      └─ Catch
         └─ Log error with customer context
            └─ Set Properties: ERROR_DETAILS
               └─ Notify operations
   └─ Set Properties: END_TIME, DURATION
      └─ Log metrics
         └─ Return Documents

Track:

  • Which route was taken
  • How long each subprocess took
  • Error rates per route
  • Volume per route

6. Version Your Subprocesses

When making breaking changes:

Old: Customer_A_Handler
New: Customer_A_Handler_V2

Process Route:
- CUSTOMER_A → Customer_A_Handler_V2 (updated)
- Old customers still using V1
- Gradual migration to V2

Benefits:

  • Parallel running of old and new logic
  • Easy rollback (change Process Route back)
  • Safe testing of new logic

7. Document Your Routing Logic

In Process Route Component description:

Component: Customer_Order_Router

Description:
Routes customer orders to appropriate handler based on Customer ID.

Routing Keys:
- CUSTOMER_A: Uses custom pricing logic (added 2025-01-15)
- CUSTOMER_B: Standard processing
- CUSTOMER_C: Requires inventory check before processing (added 2025-02-01)
- Default: Logs unknown customer and notifies ops team

Last Updated: 2025-02-15
Owner: Integration Team

8. Limit Subprocess Complexity

Keep subprocesses focused:

✅ Good Subprocess (focused):
  - Validate customer data
  - Map to standard format
  - Return results

❌ Bad Subprocess (too much):
  - Validate data
  - Map to standard format
  - Call 5 different APIs
  - Write to 3 databases
  - Send 10 notifications
  - Generate reports
  - Archive everything

If subprocess is too complex, break it into:

  • Main subprocess (called by Process Route)
  • Sub-subprocesses (called by Process Call from main subprocess)

Common Pitfalls and How to Avoid Them

Pitfall 1: Forgetting to Deploy Subprocesses First

Problem:

1. Deploy Process Route component first
   ↓
2. Error: Referenced subprocess "Customer_A_Handler" not found

Solution:

  • Always deploy subprocesses before Process Route component
  • Create deployment checklist
  • Use deployment packages to enforce order

Pitfall 2: Route Key Mismatches

Problem:

Document has: customer_id = "customer_a" (lowercase)
Route keys expect: "CUSTOMER_A" (uppercase)
Result: Falls through to default route

Solution:

In parent process, normalize the route key:

Set Properties Step:
  - ROUTE_KEY = uppercase({1:customer_id})

Process Route:
  - Route By: {1:ROUTE_KEY}

Pitfall 3: Not Using Passthrough When Needed

Problem:

Subprocess: Data Passthrough = OFF
Result: 
  - 1000 documents = 1000 separate subprocess executions
  - Massive resource consumption
  - Slow processing

Solution:

  • Default to Passthrough = ON
  • Only disable if you specifically need separate executions

Pitfall 4: Missing Default Route

Problem:

Unknown customer arrives
→ No matching route key
→ Process fails with error
→ Documents lost

Solution:

  • Always define default route
  • Default route should:
    • Log the unexpected value
    • Notify operations
    • Archive document safely
    • Return gracefully (don’t crash)

Pitfall 5: Hardcoding Subprocess Names

Problem:

Process Route Component:
  Key: CUSTOMER_A → Process: "Customer_A_Handler_PROD"
  
Problem: Different names in Dev/Test/Prod
  - Dev: Customer_A_Handler_DEV
  - Test: Customer_A_Handler_TEST  
  - Prod: Customer_A_Handler_PROD
  
Result: Must maintain different Process Route configs per environment

Solution:

Use same subprocess names across all environments:
  - Customer_A_Handler (same everywhere)

Use extensions to vary behavior, not subprocess names

Pitfall 6: Not Handling Return Documents Properly

Problem:

Subprocess has multiple Return Documents steps
Parent doesn't know which branch to follow

Solution:

Standardize Return Documents labels:

All subprocesses:
  - Success path: "Success" 
  - Error path: "Errors"
  - Warning path: "Warnings"

Parent process:
  - Knows to expect these exact labels
  - Can handle each consistently

Pitfall 7: Over-Engineering with Process Route

Problem:

Using Process Route for 2 routing paths
(Route step would be simpler)

Solution:

Use Process Route when:
  ✅ 5+ routing paths
  ✅ Frequently adding new paths
  ✅ Need independent deployment

Use Route step when:
  ✅ 2-4 routing paths
  ✅ Rarely changes
  ✅ Simple branching logic

When NOT to Use Process Route

Process Route is powerful, but not always the right tool.

Don’t Use When:

1. Simple 2-3 Way Branching

❌ Overkill:

Process Route for:
  - Route 1: Process_A
  - Route 2: Process_B
  - Default: Process_C

✅ Use Route Step Instead:

Route by {1:type}
  ├─ "TypeA" → Process logic A
  ├─ "TypeB" → Process logic B
  └─ Default → Process logic C

Why? Simpler, fewer components, no deployment complexity

2. Sequential Processing

❌ Wrong Tool:

Process Route to call steps in sequence:
  - Step 1: Validate
  - Step 2: Transform
  - Step 3: Load

✅ Use Process Call Instead:

Process Call: Validation_Subprocess
└─ Process Call: Transform_Subprocess
   └─ Process Call: Load_Subprocess

Why? Process Call is simpler for sequential workflows

3. All Logic Fits in One Process

❌ Unnecessary:

Parent Process (20 shapes)
└─ Process Route
   └─ Subprocess (5 shapes)

✅ Just Use One Process:

Single Process (25 shapes total)
  - No subprocess needed
  - Simpler to debug
  - Easier to maintain

Why? Don’t create subprocesses unless complexity demands it

4. Routing Doesn’t Change

❌ Over-Engineering:

Process Route for routing that never changes:
  - Always route to same subprocess
  - No variation needed
  - Static configuration

✅ Use Process Call:

Process Call: Standard_Subprocess
(Fixed, simple, efficient)

5. Within-Process Branching

❌ Wrong Concept:

Using Process Route for decisions within same process:
  - If value > 100
  - If customer type = "Premium"

✅ Use Decision or Route Step:

Decision: {1:value} > 100
  ├─ True → Premium path
  └─ False → Standard path

Advanced Patterns

Pattern 1: Cascading Process Routes

Scenario: Multi-level routing (Region → Country → Customer)

Architecture:

Parent Process
└─ Process Route: Region_Router
   ├─ NA_Handler
   │  └─ Process Route: NA_Country_Router
   │     ├─ US_Handler
   │     └─ CA_Handler
   └─ EU_Handler
      └─ Process Route: EU_Country_Router
         ├─ UK_Handler
         ├─ DE_Handler
         └─ FR_Handler

Benefits:

  • Hierarchical routing
  • Easy to add countries within regions
  • Each level independently deployable

Caution:

  • Adds complexity
  • More deployment components
  • Only use if truly needed

Pattern 2: Process Route with Parallel Processing

Scenario: Route to subprocess, then process results in parallel

Parent Process
└─ Process Route: Customer_Router
   └─ (Returns processed orders)
      └─ Flow Control: Parallel Processing
         ├─ Branch 1: Write to Database
         ├─ Branch 2: Send to Warehouse
         └─ Branch 3: Notify Customer

Use When:

  • Subprocess returns data
  • Multiple independent actions needed on results
  • Want to maximize throughput

Pattern 3: Conditional Process Route

Scenario: Sometimes route to subprocess, sometimes process in parent

Parent Process
└─ Decision: Needs Custom Logic?
   ├─ Yes → Process Route: Custom_Logic_Router
   └─ No → Standard processing in parent
      └─ Continue...

Use When:

  • Most cases handled by standard logic
  • Only some cases need custom subprocesses
  • Want to minimize subprocess calls

Pattern 4: Process Route with Aggregation

Scenario: Route to different subprocesses, collect all results, then aggregate

Parent Process
└─ Process Route: Multi_Target_Router
   (Multiple subprocesses return results)
   └─ Collect all Return Documents branches
      └─ Data Process: Combine all results
         └─ Aggregate and summarize
            └─ Final output

Use When:

  • Need results from multiple specialized handlers
  • Aggregate results for reporting
  • Compare outputs from different processors

Conclusion

The Process Route Step is one of Boomi’s most powerful features for building scalable, maintainable integrations. It transforms rigid, hardcoded workflows into flexible, runtime-adaptive architectures.

Key Takeaways

Use Process Route when you need: ✅ Dynamic subprocess selection based on data ✅ Frequent addition of new routing paths ✅ Independent deployment of routing logic and subprocesses ✅ Customer/partner/document-specific processing at scale ✅ Ability to modify routing without changing parent process

Key Benefits:

  • Scalability: Add 100 customers without 100 processes
  • Maintainability: Change routing logic without touching parent
  • Flexibility: Adjust behavior at runtime based on data
  • Deployment: Independent component deployment
  • Testability: Test each subprocess in isolation

Remember:

  1. Always enable Data Passthrough in subprocesses (unless specific reason not to)
  2. Always provide a default route
  3. Deploy subprocesses first, then Process Route component, then parent
  4. Use consistent Return Documents labels
  5. Document your routing logic clearly
  6. Monitor routing metrics

The Golden Rule:

If you’re building the same process with minor variations more than 3-4 times, you probably need Process Route instead.

By mastering Process Route, you’ll build integrations that adapt to business changes without constant redeployment—the hallmark of enterprise-grade integration architecture.

Additional Resources

Have questions about Process Route? Share your use cases or challenges in the comments!

Subscribe to Integration Insider for more Boomi deep-dives and architectural patterns.

Leave a Reply

Your email address will not be published. Required fields are marked *